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[57] 



ABSTRACT 



An IEEE 1394 serial bus, during bus initialization, transmits 
a plurality of self -ID packets across the bus. Each node on 
the bus is operable to receive the self-ID packet from the bus 
(140) via receiver (146). Asynchronous packets and isoch- 
ronous packets are stored in a FIFO (166) for later use by a 
host interface (150). The self -ID packets are verified by a 
hardware circuit (170) that provides verification of the 
self-ID packets as they are received without requiring the 
software to later evaluate the self-ID packets from storage in 
the FIFO (166). If an error is determined, this is stored in 
registers (164) for later processing by the host interface 
(150). 

9 Claims, 13 Drawing Sheets 



190- 
192- 
194- 



SELF-IO SNOOPER 



SELF- ID BEGIN 



RECEIVE SELF-ID 



196- 



HARDWARE SNOOPER: 

MONITORS AND VERIFIES THE INTEGRITY OF EACH SELF- ID PACKET 
MONITORS AND REPORTS THE NUMBER OF NODES IN THE NETWORK 
MONITORS AND VERIFIES THE GAP COUNT REPORTED EACH SELF-ID PACKET 
MONITORS AND RECORDS THE IRM NODE ID 



200- 




REPORT SELF- ID PERIOD COMPLETE 
AND THAT RESULTS ARE AVAILABLE 
IN STATUS REGISTERS 



202 



X DONE ) 



3/22/04, 



EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 1 of 13 



6,157,972 




FIG, 1 

32- 
34- 



BRIDGE 



SYSTEM 



1/0 


I/O 






28 


38 



I/O 



APPLICATION 



I 



SERIAL 
BUS 
MANAGER 

56 



C=C>| TRANSA CTION LAYER 



-50 



FIG, 2 



LINK LAYER 



III 



C=> PHY LAYER 



-52 
58 



SERIAL BUS 



72 



70 

< ^ FIFO | C=C> 

R/W FIFO 
CONTROL 



71 



LINK 
52 



D[0:7] 
CTL[G:1] 



LREQ 
SCLK 



60 
62 
64 

y 

66 



■DIRECT DIRECT - 

■BACKPLANE 

■CLK25 



FIG. 3 



PHY 
54 



58 



SERIAL BUS 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 2 of 13 



6,157, 



CO 



CO 

o 

Q. 
CO 
LU 

a: 



CO 



< o 



o 



CO 



1 — d. 



CO 
LiJ 
ZD 

o 

UJ 



M 



CD 



<c o 



■<C UJ 



X 



CL 



CO 



UJ 
CO 



o H 



i 

o 



o 



>- 
< 



i, 

o 



UJ 

:n 
o - 



1 

o 

o 
o 
_J 
cn 

1 



CO 

I — 

o 
o 

2 

CX3 



or 



CO 
UJ 

p 



o 



CO 



o 
o 



PACKET HEADER 
(ALL FORMATS) 



DATA BLOCK 
(SOME FORMATS) 



CO 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 3 of 13 



6,157,972 



REQUESTER 
LINK LAYER 



LINK 
REQUEST" 



LINK 
CONFIRMATION 



RESPONDER 
LINK LAYER 



4V0 



'/V 



FIG. 5 



'LINK INDICATION 
•LINK RESPONSE 



94- 



PHYSICAL PHYSICAL 
CONNECTION jjfS CONNECTION §b 



80 



96- 



n 

SERIAL 




n n 
SERIAL 


84 X. 


n n 
SERIAL 


BUS 




BUS 




BUS 



82 



100- 



PHYSICAL 
CONNECTION |3 



^98 

PHYSICAL 
CONNECTION §A 



86- 



PHYSICAL 
CONNECTION §2 



88- 



n n n 



SERIAL 
BUS 



FIG. 7 



PHYSICAL 
CONNECTION 



104- 



92- 



— \ 

n r 


\ t\ 


n 


SERIAL 
BUS 




SERIAL 
BUS 



D__a 



SERIAL 
BUS 



-94 



"^96 



-102 



SERIAL 




n n 
SERIAL 


BUS 




BUS 



-90 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 4 of 13 



6,157,972 



110- 



114 



120 §\ 



BRANCH 

77 



NODE B 



§2 122 



OFF OFF OF 



LEAF 
OF 



OF 



OFF 



NODE A 



f1 



BRANCH 



12 #3 #4 is #6 in 

FIG. 8 



m 

OFF 



116-^ 



124 #2 



7\ 



^112 
NODE D 



126 



12 



LEAF 



NODE C 



118^ 



LEAF 



NODE E 



HQ- 



ROOT 
CH CH 



114 



120 #1 

W 



iii> 



NODE B 



#2 122 



P 
LEAF 

OFF OFF OFF OFF OFF OFF 

mwinnnnnni 

12 #3 #4 1^5 #6 |7 



NODE A 



1 



#1 



P 

BRANCH 
CH CH 



12^ #2 



FIG. 9 



#1 



116- 



OF 



77 



^112 
NODE D 



' H- 



126 



12 



LEAF 



NODE C 



118- 



P 
LEAF 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent Dec. 5, 2000 sheet 5 of 13 



6,157,972 



114 



110- 



120 

GRANT 

I 1 



ROOT 
CH CH 



|1 



7? 



NODE B 



122 



SELF_IO_COUNT=0 



DAT/LPREFIX " 



NODE A 



P 

NODE |0 
OFF OFF OFF OFF OFF OFF 

12 13 #4 §5 |6 #7 

FIG. 10 dUl 



116- 



124 n 



p 

BRANCH 
CH CH 



TV 



/-112 
NODE D 



126 



n 



OFF P 
LEAF 



NODE C 



118-^ 



1 



P 
LEAF 



NODE E 



114 



110- 



120 
\ GRANT 

IT 



|1 



ROOT 
CH CH 



NODE B 



#2 



SELF_ID_COUNT=0 



DATA_PREFIX DATA_PREFIX 



P 

NODE |0 
OFF OFF OFF OFF OFF OFF 

mnnnnnni™ 

n #3 #4 #5 I 

FIG. 11 

116^ 



NODE A 



D ATA^PREFIX 





NODE C 



118-^ 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent Dec. s, 2000 sheet 6 of 13 6,157,972 



110- 



ROOT 
CH-I CH 



DATA. PREFIX 



120 #1 



7T 



114 



/ 
/ 
/ 



lOENT.DONE 



NODE B 



122 



SELF_1D_C0UNT=1 



NODE iflO NODE A 

OFF OFF OFF OFF OFF OFF 

yyuuyuuuyuuu 

n #3 #4 15 #6 II 

FIG. 12 iM 



#1 



p 

BRANCH 
CH-I CH 



124 n 



77 



116^ 



^112 
NODE D 



126 



OFF P 
LEAF 



NODE C 



18- 



1 



P 

LEAF 



NODE E 



110- 



ROOT 
CH-I CH 



#1 



120 

DAT/LPREFIX3^^^^ 



114 



1 



NODE B 



n 



122 



SELF_ID_C0UNT=1 



GRANT 



NODE i^O 



OF 



OFF OF 



OF 



OF 



OF 



n #3 #4 #5 me 

FIG. 13 



NODE A 



1 



#1 



116- 



124 #2 



P 

BRANCH 
CH CH 



M12 
NODE D 



1^ 



OFF P 
LEAF 



W 126 



NODE C 



118^ 



1 



P 
LEAF 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent Dec. 5, 2000 Sheet 7 of 13 6,157,972 



110- 



122 

s, 



ROOT 
CH-I CH 



DAT/LPREFIX \ 



112 



7T 



1 



NODE B 



12 



124 



SELF_ID_C0UNT=1 



GRANT 



NODE |0 
OFF OFF OFF OFF OF OFF 

yyyuyuuyyuyu 

n #3 #4 #5 #6 #7 



NODE A 



#1 



#2 



GRANT 



116- 



p 

BRANCH 
CH CM 



OFF P 
LEAF 



^114 
NODE D 



#3 

DATA,PR EFIX 
•zzzzzzzzz 



NODE C 



118- 



1 



-128 



|1 



P 
LEAF 



NODE E 



110- 



ROOT 
CH-I CH 



DATA_PREF|X 



12 

A. 



12^ #1 



NODE B 



SELF_ID_C0UNT=2 



DATA_PREFIX 



GRANT 



P 

NODE #0 
OFF OFF OFF OFF OFF OFF 

yyyyyyyyyyyy 

n #3 #4 #5 #6 #7 



FIG. 15 



NODE A 



1 



.^124 
#1 



12 



GRANT 



P 

BRANCH 
CH CH 



126 



il 



/-114 
NODE 0 



128 



DATA. DATA_PREFIX 
1^2 PREFIX 





OF 


F P 




P 


116-^ 


NODE #1 


NODE C ^^g^ 


LEAF 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 8 of 13 



6,157,972 



110- 



ROOT 
CH-I CH 



112 



122 #1 



NODE B 



SELF_ID_C0UNT=2 



P 

NODE #0 



OF 



OFF OF 



OF 



OF 



OF 



NODE A 



|2 #3 #4 |5 16 §7 



126- 





12 

DATA_PREFIX 



> IDENLDONE 
§2 



NODE C 



NODE E 



110- 



ROOT 
CH-I CH 



DATA-PREF IX 



112 



122 



NODE B 



#2 



124 



SELF_ID_C0UNT=2 



GRANT 



NODE #0 
OFF OFF OFF OFF OFF OFF 

mnnnnmnnnm 

n #3 h #5 #6 #7 

FIG. 17 #1 



NODE A 



1 



P 

BRANCH 
CH-I CH 



12 

DATA_PREFIX 



126 



116^ 



OFF 
NODE iSII 



! 



^114 
NODE D 



#3 128 



#2 



NODE C 



118- 



P 
LEAF 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent Dec. 5, 2000 sheet 9 of 13 6,157,972 



110- 



ROOT 
CH-I CH 



#1 



120 

0AT/LPREFIxf5=#Z22Z2za 



112 



7T 



11^ 



NODE B 



12 



122 



SELF_ID_C0UNT=2 



GRANT 



P 

NODE |0 
OFF OFF OFF OFF OFF OFF 

mnnnnnnnra 

#2 #3 #4 15 IS p 



NODE A 



1 



#1 



P 

BRANCH 
CH-I CH 



§2 



D ATA-PREFIX 



124 



FIG. 18 



#1 



116- 



7T 



3Z 



OFF P 
NODE |1 



^114 
NODE D 



GRANT c. 



§2 



NODE C 



118- 



p 

LEAF 



-126 



NODE E 



110- 



112 



12^ |1 



ROOT 
NODE #4 

CH-I CH-I 

"77 



NODE 6 



|2 J|22 



SELF_1D_C0UNT=5 



P 
LEAF 
NODE §0 
OFF OFF OFF OFF OFF O FF 

mwm™ 

P »3 J4 1(5 (6 II 



NODE A 



#1 



116- 



124 §2 



P 

BRANCH 
NODE #3 
CH-I CH-I 



OFF P 

LEAF 
NODE |1 



^114 
NODE D 



125 



§2 



NODE C 



118- 



1 



P 
LEAF 
NODE § 



NODE E 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 10 of 13 



6,157,972 



BUS INITIALIZATION PROCESS 



BUS-RESET 
PHASE 



TREE-ID 
PHASE 



SELF- 10 PACKETS 



IDLE 



BUS- 



RESET 



FIG. 20 



SUBACTION 
GAP STATUS 



transmitted first 



10 


phy_IO 


0 


L 


gap_cnt 

L 1— 1 ■ ■ ■ 


sp 


del 


c 


pwr 


pO 


pl 


P2 


i 


m 










logical inverse 


of first quodlet 














transmitted first 








self- ID pocket 


10 










transmitted lost 


10 


phy_ID 


1 


n 


rsv 


pa 


pb 


pc 


pd 


pe 


Pf 


P9 


ph 


r 


m 


logicol inverse of first quodlet 



self-ID pocket #1. |2 ond #3 
po pb pc pd pe pf pq 



ph 



pM #1 0 p3 p4 p5 p6 p7 p8 p9 plO 

pkt #2 1 p11 p12 p13 pl4 pl5 p16 pl7 pl8 

pkl #3 2 pl9 p20 p21 p22 p23 p24 p25 p26 

for n=3 through 7, fields po through ph ore reserved 



transmitted lost 



FIG. 21 



■140 



1394 
BUS 



PHYSICAL 
LAYER 



142 



PHYSICAL 
INTERFACE 

144 



148 

\ 


152 

/ 


TRANSMIFER 




TRANSMIT 




FIFO 



RECEIVER 
146 



ASYNCHROMOUS 154 
PACKETS rr- 



ISOCHRONOUS 
PACKETS _ 



SELF-ID 
PACKETS 



158 



160 



LARGE 
RECEIVE 
FIFO 

m 



HOST 
INTERFACE 

150 



162 



FIG. 22 

(PRIOR ART) 



164- 



GENERAL 
PURPOSE 
REGISTERS 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 11 of 13 



6,157,972 



1394 
BUS 



■140 



PHYSICAL 
LAYER 

142 



FIG. 23 







PHYSICAL 




INTERFACE 




144 









148 


152 


TRANSMITTER 




TRANSMIT 




FIFO 



RECEIVER 
146 



170- 



3 



ASYNCHRONOUS 
PACKETS I 



154 



ISOCHRONOUS 
PACKETS 



168-^SELF-ID PACKETS 



158 



SMALL 
RECEIVE 
FIFO 



166 



SELF-ID SNOOPER (PROVIDES 
VERIFICATION OF SELF- ID 
PACKETS AND ISOCHRONOUS 
RESOURCE MANAGER INFORMATION) 





HOST 
INTERFACE 




150 


162 






1 




172 


GENERAL 
PURPOSE 
REGISTERS 


\ 

164 



174- 
176- 

178- 
180- 



FIG. 24 

(PRIOR ART) 



METHOD (PRIOR ART) 



SELF-ID BEGIN 



RECEIVE SELF- ID 



I 



STORE SELF-ID TO LARGE FIFO 




184- 



186- 



SOFTWARE READS SELF-IDS STORED IN LARGE FIFO AND: 
MONITORS AND VERIFIES THE INTEGRITY OF EACH SELF-ID PACKET 
MONITORS AND REPORTS THE NUMBER OF NODES IN THE NETWORK 
MONITORS AND RECORDS THE IRM NODE ID 

i 



BIG DELAY WHILE SOFTWARE PERFOMS SELF-ID VERIFICATION 
188 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent Dec. 5, 2000 sheet 12 of 13 6,157,972 



190- 



SELF-IO SNOOPER 



192- 



194- 



SELF-ID BEGIN 



RECEIVE SELF-ID 

1 



HARDWARE SNOOPER: 

MONITORS AND VERIFIES THE INTEGRITY OF EACH SELF- ID PACKET 
196-^ MONITORS AND REPORTS THE NUMBER OF NODES IN THE NETWORK 

MONITORS AND VERIFIES THE GAP COUNT REPORTED EACH SELF-IO PACKET 
MONITORS AND RECORDS THE IRM NODE ID 



200- 




REPORT SELF-ID PERIOD COMPLETE 
AND THAT RESULTS ARE AVAILABLE 
IN STATUS REGISTERS 



FIG. 25 



3/22/04, EAST Version: 2.0.0.29 



U.S. Patent 



Dec. 5, 2000 



Sheet 13 of 13 



6,157,972 



FIG. 26 



206- 




SIGNAL BUS RESET START. 
SELF-ID/IRM DATA INVALID 




212 



UPDATE LOCAL NODE ID, NODE 
COUNT. ISOCHRONOUS RESOURCE 
MANAGER NODE ID, RESULTS OF 
SELF- ID VERIFY. RESULTS OF GAP 
COUNT VERIFY AND SIGNAL BUS 
RESET COMPLETE AND DATA VALID 



UPDATt^ODE COUNT 



-216 



SNOOP SELF- ID FOR CANDIDATE 
ISOCHRONOUS RESOURCE MANAGER 



I 



-218 



PERFORM VERIFICATION OF 
SELF- ID PACKET/QUADLET: 

1. INVERTED QUADLET CORRECT? 

2. IF LAST SELF- ID. IS IT ALL CHILD? 

3. DOES EXPECTED LOCAL NODE ID EQUAL ACTUAL? 

4. NODE ID INCREMENTED BY 1? 

5. NODE ID'S EQUAL IN MULTLQUADLET SELF-ID? 

6. SELF-ID/INVERTED-SELF- 10 PHASE ERROR? 

7. NODE ID INCREMENT? 

8. GAP COUNT CORRECT? 



-220 




3/22/04, EAST Version: 2.0.0.29 



6,157,972 



APPARATUS AND METHOD FOR 
PROCESSING PACKETIZED INFORMATION 
OVER A SERIAL BUS 

This application claims priority under 35 US C §119 (e) 5 
(1) of provisional application number 60/067,618, filed Dec. 
5, 1997. 

TECHNICAL FIELD OF THE INVENTION 

The present invention pertains in general to receiving data 
from a serial bus and, more particularly, to a method for 
identifying nodes on the serial bus. 



BACKGROUND OF THE INVENTION 



IS 



20 



25 



The IEEE has approved a new standard under IEEE 1394 
for a high-performance serial bus cable environment that 
includes a network of logical nodes connected by point-to- 
point links called physical connections. The physical con- 
nections consist of a port on each of the nodes and a cable 
disposed therebetween. A node can have multiple ports, 
which allows a branching multi-hop interconnect. The limi- 
tations on this topology are set by the requirement for the 
fixed round-trip time required for the arbitration protocol. 
The default timing set after a bus reset is adequate for 16 
cable hops, each of 4.5 meters for a total of 72 meters. The 
maximum number of nodes supported on a single bus is 63. 

Whenever a node is added to or removed from the 1394 
serial bus, a bus reset occurs and forces all nodes to a known 
state. After a bus reset, the tree identify (ID) process 
translates the general network topology into a tree, where 
one node is designated a root, and all the physical connec- 
tions are labeled as either a parent, a child or as unconnected. 
The imconnected ports are labeled as "ofiF' and do not 
participate any further. The tree must be acyclic, meaning no 
loops allowed; otherwise, the tree ID process win not be 
completed. 

The 1394 cable environment supports multiple data rates 
of 98.304, 196.608, 393.216 megabits per second. The 
lowest speed is known as the base rate, and all ports that 4q 
support a higher data rate must also support the lower data 
rate. Nodes capable of data rates greater than the base rate 
exchange speed information with its peers through its attach 
ports during the speed signaling phase of normal bus arbi- 
tration. If a peer node is incapable of receiving high-speed 45 
data, then data will not propagate down that path. Data will 
only be propagated down paths that support the higher data 
rate. 

During data packet transmission, the source node sends a 
speed code, format and transaction codes, addresses of the 50 
source and destination nodes and data in a packet form. The 
destination field in this packet is utilized by each node's link 
layer to determine if it is the recipient of the transmitted data. 
The maximum speed at which a data packet can be trans- 
mitted depends upon the bus topology and the data trans- 55 
mission speed supported by the nodes on the bus. To 
determine the optimum speed at which a data packet may be 
sent, the maximum supported speeds of the transmitting and 
receiving nodes, as well as the maximum speeds of any 
nodes connected between these nodes, must be determined. 60 
The optimimi speed for data transmission is equal to the 
highest speed which is supported by all the nodes, which arc 
required to participate in the transmission of the data packet. 

The IEEE 1394 bus has a defined topology which is 
referred to as acyclic topology in that there are no loops in 65 
the bus. The bus is comprised of a plurality of nodes which 
are interconnected by physical connections. This is referred 



to as the cable topology. There is also a backplane topology 
which allows a plurality of nodes to exist on a common 
backplane. However, all of the nodes must have some 
recognizable ID on the bus. In the IEEE 1394 standard, there 
is a defined sequence that is processed to add a new node to 
the system. This is due to the fact that, unlike an Ethernet® 
network card, the node in the IEEE 1394 bus does not have 
a unique physical ID due to a hardware setting. As such, the 
network nodes will configiue themselves, determine the 
architecture of the system, i.e., the tree structure of the 
network, and then determine their ID on the network. 

Whenever a new device is added to the serial bus, it must 
obtain a logical address on the bus. To do this, it initiates a 
bus reset operation, which is followed by a tree identification 
operation. After the tree structure is determined, then the 
system will initiate transmission of self ID packets from 
each of the nodes in a defined order. This defined order 
allows only one node at a time to generate self ID packets, 
with the other nodes receiving the self ID packets for storage 
therein. During the self ID process, each node will receive 
all of the self ID packets that are transmitted on the bus and 
store them in a buffer. After storage, they must evaluate the 
self ID packets. If, for some reason, there is some problem 
with the integrity of a received self ID packet from another 
node, the receiving node will then initiate a bus reset. The 
disadvantage to the present systems are that they require 
sufficient memory to store all of the self ID packets firom all 
of the nodes during the self ID portion of a bus initialization 
operation prior to evaluation thereof. Once all of the self ID 
packets have been received and stored, they are evaluated 
from an integrity standpoint and then, if there is a problem 
with integrity, a bus reset is sent to all of the other nodes. 
This requires a significant amount of storage and software 
for processing. 

SUMMARY OF THE INVENTION 

The present invention disclosed and claimed herein com- 
prises a method for processing packetized identification 
information over a serial bus carrying data packets. This 
packetized identification information is utilized by each 
node in a network for self-identifying itself on the network. 
Each node includes a monitor for monitoring the data 
packets received from the serial bus during a self-ID pro- 
cess. The node then recognizes that the data packet received 
is a self-ID packet, which self-ID packet comprises data 
placed on the serial bus by other nodes on the serial bus to 
identify those other nodes to aU remaining nodes on the 
serial bus. Each node processes the recognized self-ID 
packets with a hardware processor to verify the integrity of 
the received self-ID packet in accordance with predeter- 
mined criteria. An error signal is generated if any of the 
self-ID packets fails to verify in accordance with the pre- 
determined criteria. 

In another aspect of the present invention, the processing 
operation occurs upon receipt of the self- ID packet with 
substantially no buffering of the self -ID packet. Therefore, 
minimal storage is required. Additionally, gap count infor- 
mation is provided in each of the self -ID packets, which gap 
count information relates to synchronization information. 
The synchronization information is extracted from the self- 
ID packet for each self -ID packet and compared with the 
synchronization for gap count information of the other 
self-ID packets. If they do not match, this will constitute an 
error which will be generated as an error signal. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and the advantages thereof, reference is now made to 
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the following description taken in conjunction with the 
accompanying Drawings in which: 

FIG. 1 illustrates an overall block diagram of a system 
utilizing the IEEE 1394 serial bus architecture; 

Fl G. 2 illustrates a simplified block diagram of the various ^ 
protocol layers in the IEEE 1394 bus; 

FIG. 3 illustrates a more detailed block diagram of the 
physical and Unk layers which interface with the FIFO; 

FIG. 4 illustrates an example of an asynchronous trans- 
mission over the serial bus; 

FIG. 5 illustrates a diagrammatic view of how the link 
layer services a transaction; 

FIG. 6 illustrates a primary packet data format; 

FIG. 7 illustrates a diagrammatic view of the acyclic 
topology for a physically connected IEEE 1394 bus; 

FIG. 8 illustrates a diagrammatic view of the cable state 
after a bus initiali2e; 

FIG. 9 illustrates a diagrammatic view of the tree of the 
cable state after the tree identify operation is complete; 

FIGS. 10-19 illustrate the cable states for the self ID 
process from start to finish; 

FIG. 20 illustrates a diagrammatic view of the timing 
diagram for the bus initialization process; 25 

FIG. 21 illustrates a diagrammatic view of a self ID 
packet; 

FIG. 22 illustrates a block diagram of a prior art serial bus 
transmitter/receiver; 

FIG. 23 illustrates the transmitter/receiver of the present 
invention; 

FIG. 24 illustrates a flow chart of the prior art operation 
of processing self ID packets; 

FIG. 25 illustrates a flow chart depicting the operation of 35 
the block diagram of FIG. 23; and 

FIG. 26 illustrates a flow chart depicting the operation of 
the isochronous resource manager protocol processor. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring now to FIG. 1, there is illustrated a block 
diagram of a system utflizing the serial bus architecture that 
is defined as the IEEE 1394 serial bus. This is defined in the 
"IEEE Standard for a High-Performance Serial Bus/' IEEE 45 
STD 1394—1995, which is incorporated herein by reference. 
A module 10 is illustrated, which module 10 includes a CPU 
12, a memory 14, an input/output (I/O) 16 and a CPU 18. 
The CPU 12, memory 14, I/O 16 and CPU 18 aU comprise 
units within the system. Each of the units 12-18 interfaces 50 
with a parallel bus 20, which is a system bus that is 
indigenous to the module 10. In addition, each of the units 
12-18 interfaces with a serial bus 22 which is referred to as 
a "backplane." The serial bus 22 operates in accordance with 
the IEEE 1394 standard and is also interfaced external to the 55 
system with a bridge 24. The bridge 24 and the module 10 
each comprise logical nodes on the serial bus. In general, the 
serial bus architecture is defined in terms of logical nodes, 
the node being an addressable entity. Each of those can be 
independently reset and identified, and more than one node 60 
may reside on a single module, and more than one unit may 
reside in a single node. A node is therefore a logical 
addressing concept wherein a module is a physical device 
which can consist of more than one node that share a 
physical interface. The address space of a single node can be 65 
direcUy mapped to one or more units. A unit can be a logical 
entity, such as a disk controller, memory, CPU, etc. Within 
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a given unit, there may be multiple subunits, which can be 
accessed through independent control registers or uniquely 
addressed with direct memory access (DMA) command 
sequences. 

Referring further to FIG. 1, it can be seen that there are 
two environments, one within the module 10 utilizing the 
backplane 22, referred to as the "backplane environment,'' 
and the other being a "cable environment." The nodes 
interfacing with the cable environment have "ports" asso- 
ciated therewith. The bridge node 24 is such a node which 
interfaces on one side to the backplane serial bus 22 and on 
the other side to a cable 26 which interfaces to a single I/O 
node 28 through one port therein. The I/O node 28 has two 
other ports, one of which is connected through a cable serial 
bus 30 to a bridge node 32. The bridge node 32 is similar to 
the bridge node 24 in that it interfaces with another system 
34, this being a module. The system node 34 can be 
substantially identical to the system 10, or any other type of 
system employing a backplane. The third port of the I/O 
node 28 interfaces through a cable serial bus 36 to one port 
of an I/O node 38, the other port thereof interfaced through 
a cable serial bus 40 to an I/O node 42. 

The cable environment in general is a physical topology 
that provides a noncyclic network with finite branches and 
extent. The medium consists of two conductor pairs for 
signals and one pair for power and ground that connect ports 
on different nodes. Each port consists of terminators, 
transceivers, and simple logic. The cable and ports act as bus 
repeaters between the nodes to simulate a single logical bus. 
The backplane environment, by comparison, comprises a 
multidrop bus. This consists of two single-ended conductors 
running the length of the backplane in the module. Connec- 
tors distributed along the bus allow nodes to "plug into" the 
bus. This system makes use of wired-OR logic that allows all 
nodes to assert the bus. 

Referring now to FIG. 2, there is illustrated a block 
diagram of the serial bus protocol. The serial bus protocol is 
comprised of three stack layers, a transaction layer 50, a hnk 
layer 52 and a physical layer 54 labeled "PHY." The 
transaction layer defines a complete response-response pro- 
tocol to perform the bus transactions required to support the 
CSR architecture (control and status registers). This pro- 
vides operations of read, write and lock. The fink layer 52 
provides an acknowledge datagram (a one-way data transfer 
with confirmation of request) service to the transaction layer 
50, It provides addressing, data checking, and data framing 
for packet transmission and reception. The link layer 52 also 
provides an isochronous data transfer service directly to the 
appMcation, including the generation of a "cycle" signal 
utilized for timing and synchronization. One link layer 
transfer is called a "sub action." 

The physical layer 54 provides three major functions. It 
translates the logical symbols utilized by the link layer 52 
into electrical signals on the different serial bus media. It 
guarantees that only one node at a time is sending data over 
the bus by providing an arbitration service. It also defines the 
mechanical interfaces for the serial bus. For each 
environment, there is provided a different physical layer, the 
cable and backplane environments. The cable physical layer 
also provides a data resynch and repeat service and auto- 
matic bus initialization. 

In addition to the three layers, there is also provided a 
serial bus management block 56 that provides the basic 
control functions and standard CSRs needed to control 
nodes or to manage bus resources. This includes a number 
of components, a bus manager component which is only 
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active at a single node that exercises management respon- 
sibilities over an entire bus, a node controller component, 
and an isochronous resource manager that centralizes the 
services needed to allocate data with another isochronous 
resource. An isochronous resource is a resource having the 5 
characteristics of a time-scale or signal that has time inter- 
vals between consecutive significant instances with either 
the same duration or durations that are integral multiples of 
the shortest duration. For the purposes of the present 
invention, the physical layer interfacing with the serial bus lO 
58 and the link layer 52 will be interfaced with a receive 
buffer (not shown). 

Referring now to FIG. 3, there is illustrated a block 
diagram of the interface between the physical layer 54 and 
the link layer 52. The physical layer 54 interfaces with the 
serial bus 58 and is operable to receive data therefrom. Data 
is passed to and from the link layer 52 through an 8-bit 
bi-directional data bus 60. Two control bits are passed 
between the physical layer 54 and the link layer 52 over a 
control bus 62. A link request is transferred to the physical 20 
54 from the link layer 52 through a request line 64, but with 
a system clock signal, SCLK, transferred from the physical 
layer 54 to the link layer 52, the physical layer 54 recovering 
this clock. 

Hereinafter, data rates are referred to in multiples of 
98.304 Mbit/s. The interface provided in the IEEE 1394 in 
the cable environment will support the following data rates: 
100 Mbit/s, 200 Mbit/s and 400 Mbit/s. The backplane 
environment will support 25 Mbitts and 50 Mbit/s. These 
rates are actually "bit" rates, independent of the encoding 
scheme. The actual clock rate in a redundant encoding 
scheme is referred to as a "baud" rate and is independent of 
the clock rate of this interface. 

The physical layer 54 has control over the bi-directional 
pins for transfening the data and the control bits. The link 
layer 52 only drives these pins when control is transferred to 
it by the physical layer 54. The link performs all unsolicited 
activities through a dedicated request pin on line 64. The 
possible actions that may occur on the interface are catego- 
rized as transmit, receive, status and request. The SCLK is 
driven by the physical layer 54 and is generally synched to 
the serial bus clock at a rate of 49.152 MHz. There is 
provided a backplane input on the link layer 52 which, if set 
high, indicates that the physical layer is in a backplane 
environment. Another input, a Clk25 input, when set high, 
forces the SCLK output from the physical layer 54 on the 
line 66 to a value of 24.576 MHz. 

When data is carried between the two chips, the width of 
the data bus 60 depends on the maximum speed of the 50 
connected physical layer 54, two bits for every 100 Mbit/s. 
Therefore, packet data for a 100 Mbit/s transmit utilizes 
D[0:1], 200 Mbit/s transfers utilize D[0:3], and 400 Mbit/s 
transfers utilize the full D[0:7 ]. The unused D[n] signals are 
driven low. The control bus 62 always carries two bits. 55 
Whenever control is transfened between the physical layer 
54 and the link layer 52, the side surrendering control always 
drives the control and data pins to a logic "0" level for one 
clocks before tri-stating its output biiffers. 

As noted above, there are four basic operations that may 60 
occur in the interface: request, status, transmit and receive. 
To request the bus or access a register in the physical layer 
54, the hnk layer 52 sends a short serial stream to the 
physical layer 54 on the request pin 64. When the physical 
layer 54 has status information to transfer to the Hnk layer 65 
52, it will initiate a status transfer. The physical layer 54 will 
wait until the interface is idle to perform this transfer, and it 
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will initiate the transfer by asserting a status bit on the 
control bus 62. It will also provide at the same time the first 
two bits of status information on D[0:1]. When the hnk 
requests access to the serial bus through the request line 64, 
the physical layer 54 arbitrates for access to the serial bus 58. 
When it wins the arbitration, it will then grant the bus to the 
link layer 52 by asserting "transmit" on the control bus 62 
for one cycle of the SCLK. It will then be idle for a single 
cycle. After sampling the "transmit" state from physical 
layer 54, the link layer 52 will then take over control of the 
interface by asserting either a "hold" or a "transmit" on the 
control bus 62. During a receive operation, whenever the 
physical layer 54 sees a "data-on" state on the serial bus 58, 
it initiates a receive operation by asserting "receive" on the 
control bus 62 and a logic "1" on each of the data pins. 
Physical layer 54 then indicates the start of a packet by 
placing the speed code on the data pins. For 100 Mbit/s, the 
data bits will be "OOxxxxxx," and for 200 Mbit/s, it will be 
"OlOOxxxx," with 400 Mbit/s being "01010000," the value 
"x" being a non operation. 

The link layer 52 will interface with a buffer in the form 
of a FIFO 70, which is controlled by a read/write FIFO 
control block 71 that defines the position of the read and 
write pointers and all accesses in and out of the FIFO. The 
other side of the FIFO 70 is interfaced with the host bus 72, 
which host bus 72 is a 32-bit bus. 

Referring now to FIG. 4, there is illustrated a subaction in 
the link layer 52 for an asynchronous transmission of a 
packet. This subaction is in the form of a request and a 
response. There is provided an arbitration sequence which is 
transmitted by a node that wishes to transmit a packet, this 
being transmitted to the physical layer 54 to gain control of 
the bus 58. The physical layer 54 may then respond imme- 
diately if it already controls the bus. This is followed by a 
data packet transmission which, for asynchronous 
sub actions, involves the source node sending a data prefix 
signal (including a speed code, if needed), addresses of the 
source node and destination nodes, a transaction code, a 
transaction label, a retry code, data, one or two cyclic 
redimdancy checks (CRCs), and a packet termination (either 
another data prefix or a data end signal). This is all followed 
by an acknowledgment field wherein a uniquely addressed 
destination returns a code indicating to the transmitting node 
the action taken by the packet receiver. Each of these 
asynchronous subactions is separated by periods of idle bus 
called "subaction gaps." This gap is disposed between the 
packet transmission and acknowledgment reception. This 
"ack-gap" is of varying lengths depending upon where the 
receiver is on the bus with respect to the senders of the link 
request and acknowledgment (ack). However, the maximum 
length of the ack-gap is sufficiently shorter than a subaction 
gap to ensure that other nodes on the bus will not begin 
arbitration before the acknowledgment has been received. 

Referring now to FIG. 5, there is illustrated a diagram- 
matic view of the manner in which the link layer 52 services 
a request. As noted above, the link layer 52 utilizes the 
request, indication, response and confirmation service primi- 
tives. The request primitive is utilized by a link requestor to 
transfer the packet to a link responder. An indication primi- 
tive indicates the reception of a packet by a link responder. 
A response primitive indicates the transmission of an 
acknowledgment by a link responder, and the confirmation 
primitive indicates the reception of the acknowledgment by 
the link requestor. Once the link request has been made, the 
system goes through an arbitration and packet transmission 
to the receiving node, which then provides a response back 
in the form of an acknowledgment to the requesting hnk 
layer, which will then confirm transmission. 
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Referring now to FIG. 6, there is illustrated a register map In a cable environment, the root is considered to be the 
for a packet that is transmitted. The packet is configured with highest node in the tree architecture. During asynchronous 
a header that contains a plurality of quadlets. Typically, the arbitration, the serial bus adds a simple scheme that splits the 
first quadlet will contain the physical ID and the last quadlet access opportunities evenly among competing nodes. This is 
wiU contain the header CRC. The header packet is followed 5 provided by a fairness protocol that is based on the concept 
by a data block which consists of a plurality of data quadlets of a fairness interval. A fairness interval consists of one or 
with the last quadlet being a data CRC quadlet. The packet more periods of bus activity separated by short idle periods 
header in the first quadlet thereof contains a transaction code called sub action gaps, and is followed by a longer period 
which defines the packet type of a primary packet. The referred to as an arbitration reset gap. At the end of each 
transaction packet code specifies the packet format and the subaction gap, bus arbitration is utilized to determine the 
type of transaction that shall be performed. This could be next node to transmit an asynchronous packet, 
such things as a write request for a data quadlet, a write The various ports for interfacing with the physical con- 
request for a data block, read requests for data quadlets and nections in a given cable environment are provided by the 
data blocks, and read responses for data quadlets and data physical layer, this physical layer also providing the arbi- 
blocks. The asynchronous data packet noted above with tration logic, which provides access to the bus. However, to 
respect to FIG. 4 is a primary data packet. ^ with each other, not only must the tree architecture 
^ r • . T^T^ « .1 • -11 . . 1 111 be known, i.e., the cable conneuration or network 
Referrmg now to FIG. 7 there is dlustrated a block configuration, but each node on the network must have a 
diagram of an acychc topology for the physical intercon- logical identifier, i.e., an ID. 

nection behveen nodes with cables, this be^^^ ^^^^^ configuration is achieved in three phases: bus 
from a backplane environinent. This topology is referred to 20 initialization, tree identification and self identification. Dur- 
as an acychd topology due to the fact that there are no -^g ^^^^^^^ ^ topology is built; each node is 
loops. There are provided a plurality of nodes 80-96 which assigned a physical node number and also sends node- 
are connected in a tree configuration. This, as described specific information that is utilize by a management layer, 
above, is a cable medium, wherein the serial bus utihzes Referring now to FIG. 8, there is illustrated a diagram- 
point-to-point physical connections between nodes with a 25 matic view of a typical arrangement of nodes in a tree 
pair of differential signals wherein the use of each pair is architecture. Whenever a node joins the bus, a bus reset 
different depending upon whether the node is art)itrating, signal forces all nodes into a special state that clears all 
transmitting data, or receiving data. Each physical connec- topology information and initiates the next phase. After bus 
tion consists of a port on each node and a cable disposed initiahzation, the only information known to a node is 
therebetween. The actual cable assembfies utilize six con- 30 whether it is a branch (more than one directly coimected 
ductor cables with small connectors. The limitations on this neighbor), a leaf (only a single neighbor) or isolated 
system are set by the requirement of the arbitration protocol (unconnected). In FIG. 8, there are provided two branch 
for a fixed round-trip time for signals. Also, the topology nodes 110 and 112, and three leaf nodes 114, 116 and 118. 
must be "acyclic" (no closed loops). Any closed loops will The branch node 110 is illustrated as having two ports 
prevent the tree-ID process described hereinbelow from 35 connected through a physical connection 120 to a single port 
completing. on node 114. Aphysical connection 122 is provided between 

Referring back to FIG. 7, the node 80 has only a single a second port on node 110 to one port on node 112. A 

port which is connected to one port on a node 82, a two-port physical connection 124 is provided between a port on node 

node, through a physical connection 94. The other port of 112 to a port on node 116. Similarly, a physical connection 

node 82 is connected through a physical connection 96 to 40 126 is provided between a port on node 112 to a port on node 

one port of the two-port node 84. The other port of node 84 118. Node 114 is labeled "Node A," Node 110 is labeled 

is connected through a physical connection 98 to one port of "Node B," Node 116 is labeled "Node C," Node 112 is 

node 86, a three -port node. A second port of node 86 is labeled "Node D" and Node 118 is labeled "Node E." In the 

connected through a physical connection 100 to one port of illustrated embodiments, the physical connections are rep- 

node 88, a three-port node. A second port of node 88 is 45 resented by two arrows which basically are an abstract 

connected through a physical connection 102 to one port of representation of the line state signaling. They do not imply 

node 90, a two -port node. The other port of node 90 is that the signaling utilizes different wire pairs for two direc- 

connected through a physical connection 104 to node 92. In tions. In fact, both directions use both pairs, and the receive 

addition, there is provided a physical connection from the signal is the result of the dominance of "V* over "z." In 

third port of node 86 to node 94, and also from the third port 50 addition, there is no particular order to the numbering; it is 

of node 88 to node 96. It can be seen that there are six just a way for this example to give each port a unique label, 

physical connections between node 80 and node 92, these After a bus initialize, a tree-ID process is entered which 

being physical cormections 94, 96, 98, 100, 102 and 104. translates the general network topology into a tree topology, 

During packet transmissions, there is only a single node where one node is designated a root and all of the physical 

transmitting on the bus, such that the entire media can 55 connections have a direction associated with them pointing 

operate in a half-duplex mode utilizing two signals: Data toward the root node. The direction is set by labeling each 

and Strb. NRZ data is transmitted on Data and then accom- connected port as a "parent" port (connected to a node closer 

panied by the Strb signal, which changes states whenever to the root) or "child" port (connected to a node further from 

two consecutive NRZ data bits are the same, ensuring that the root). Any unconnected ports are labeled "off" and do not 

a transmission occurs on either Data or Strb for each data bit. 60 participate in further arbitration processes. Any loop in the 

Aclock that transitions each bit period can be derived from topology is detected by a configuration time-out in the 

the exclusive-or of Data with Strb. The arbitration mode tree -ID process. When the tree-ID process is complete, the 

guarantees that only one node will be transmitting at the end example configuration will have each connected port labeled 

of arbitration. In this arbitration process, typically the node child (pointing to a child node) or parent (pointing to its 

with the highest natural priority (highest arbitration number 65 parent node). This is illustrated in FIG. 9. 

on a backplane and closest to the root on a cable) will always In FIG. 9, the node 110 is determined to be the root node, 

win. However, it is noteworthy that the selection of the root node 
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is not topology dependent. It is completely acceptable that 
the root node also be a leaf. The only requirement is that the 
cycle master (not shown) also has to be the root, since the 
root has the highest natural priority. In general, asynchro- 
nous arbitration is utilized whenever a Hnk layer wants to 
send packets "as soon as possible," and this is only adequate 
for nodes that do not require a guaranteed high bandwidth or 
low latency or a precise timing reference. Data such as that 
related to digital sound or instrumentation are more effi- 
ciently handled with isochronous arbitration. This is facili- 
tated by giving the highest priority access to a "cycle 
master" that maintains a common clock source. This cycle 
master attempts to transfer the special time request called a 
"cycle Stan" at specific intervals set by a "cycle synch" 
source. If a transfer is in progress when the cycle synch 
occurs, then the cycle start will be delayed, causing signifi- 
cant jitter in the start time of the transfer. In addition to 
having the highest natural priority, the node that has all of its 
connected ports identified as children becomes the root. A 
particular node can bias itself toward becoming the root by 
delaying participation in the tree-ID process. Usually, the 
node that waits the longest time becomes the root. 

Once the tree topology has been determined, the next step 
is to provide each node an opportunity to select a unique 
physical ID and identify itself to any management entity 
attached to the bus. This is required to facihtate low-level 
power management and the building of a system topology 
map needed to determine the speed capabihties of each data 
path. 

The self-ID process utilizes a deterministic selection 
process, wherein the root node passes control of the media 
to the node attached to its lowest numbered connection port 
and then waits for that node to send an "ident_done" signal 
indicating that it and all of its children have identified 
themselves. The root then passes control to its next highest 
port and waits for that node to finish. When the nodes 
attached to all of the ports of the root are finished, the root 
itself does a self -identify. The child node utilizes the same 
process in a recursive manner: the completion of a self-ID 
process is indicated by the bus going idle for a subaction 
gap- 

Sending the self-ID information is done by transmitting 
one to four very short packets at the base rate onto the cable 
that include the physical ID. The physical ID is simply the 
count of the number of times a node passes through the state 
of receiving self -ID information before having its own 
opportunity to send self-ID information, i.e., the first node 
sending self-ID packet(s) chooses 0 as its physical ID, the 
second chooses 1, and so on. A node is not required to 
decode the self -ID packet; it merely has to count the number 
of self-ID sequences since the bus reset (this is the number 
of times the self-ID receive state is entered). The manage- 
ment information included in the self-ID packet includes 
gaps for the gap timer settings, the power needed to turn on 
the attached link layer, the state of the various ports 
(unconnected, connected to child, connected to parent), and 
data rate limitations. 

Referring now to FIGS. 10-19, there are illustrated dia- 
grammatic views of the sequence of operations required for 
a self-ID process. In this example, there are illustrated the 
five nodes 110-118 with the state illustrated in FIG. 10 
illustrating the state of the self-ID process immediately 
following the tree-ID process. At this point, the "self_ID_ 
count" values of all nodes are set equal to "0." The root starts 
this process by sending a grant to its lowest number iden- 
tified port in a data_prefix to all other ports. Note that an 
unconnected port is automatically flagged as self-identified. 
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The grant from the root node 110 is sent to node 114 with the 
data_prefix sent to node 112. 

When a node receives the grant, the node 114 in FIG. 10, 
it propagates to its lowest numbered identified child port or, 
if there is no requesting child, takes the current value of the 
self_JD_count as its node ID and starts sending its self- 
identification information. The start of this information is 
indicated by a data prefix. This is illustrated in FIG. 11 
wherein the data_prefix is sent from node 114 to node 110. 
When the root node 110 sees this datajrefix, it then 
withdraws its grant to node 114. Meanwhile, node 112, the 
other node connected to the child port of node 110, has seen 
the data_prefix sent by node 110, and it therefore propagates 
the data_prefix to its children on physical connections 124 
15 and 126, nodes 116 and 118, respectively. At this point, the 
data_prefixes are all directed away from node 114, such that 
it can start sending the self-ID information. This is encoded 
in small 32-bit packets, with the first packet containing 
power requirements, performance capabilities, and the status 
20 of the first four ports. In this example, it is noted that node 
114 has seven ports, and therefore needs to send a second 
self-ID packet to identify itself fully. The first packet is 
terminated with the data_prefix, which holds the bus until 
the second packet is sent. The second packet terminates 
normally with the data_end. All other nodes see the normal 
packet termination and utilize this event to increment their 
self_ID_count. Note that the bus-holding termination of 
the first ID packet does not cause a self_ID_count to be 
incremented. Additionally, all self-ID packets are sent at the 
base rate (98.304 Mbit/s). 

When node 114 finishes sending its self-ID packets, it 
then sends an ident done to its parent, node 110. The parent 
node 110 flags that port as identified, sends a data__prefix to 
the node 114, and then continues to send idle to its other 
ports. This state is iUustrated in FIG. 12. When node 114 
sees the data_prefix from the parent node 110, it then leaves 
self-ID mode and, at this time, could start normal arbitration. 
However, as long as the self-ID process, there wfll never be 
an idle period long enough for the physical layer to request 
the bus. Nodes 112, 116 and 118 respond to the idle by 
incrementing their self_ID__count value. 

In the next step, illustrated in FIG. 13, node 110, the root 
node, sends a grant to its lowest numbered identified child 

port, the one connected to node 112. It also sends a data 

prefix to its other ports, that being the one connected to node 
114. This indicates the start of a bus grant for the second 
node of self -identity. The next step, illustrated in FIG. 14, 
requires that node 114, having unidentified child ports, to 
pass a grant from node 110 to its lowest numbered node, 
node 116, and then sends a data_prefix to the other child 
ports, that being node 118. This constitutes the finish of the 
bus grant for the second node self -identity. 

Node 116, as noted hereinabove, does not have any 
unidentified children. Therefore, it responds by taking the 
value of self_ID_count as its node _JD, sending a data_ 
prefix and a single self -ID packet as illustrated in FIG. 15. 
Only a single self-ID packet is required, since node 116 has 
only a single pair of ports. As the other participating nodes 
see the normal termination Une state at the end of the self-ID 
packet, they all increment their self-ID counters. Node 112 
has already left the self -ID process; therefore, it sees all 
successive self-ID packets as normal receive packets. 

In the next step, illustrated in FIG. 16, node 116 sends an 
ident_done to its parent node, node 114. Node 114 then 
responds by labeling that port as identified, sending a 
data_prefix on the newly identified port and continuing to 
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send an idle on each of its other ports, the child port 
connected to physical connection 128 and node 118. 

The next step, that depicted in FIG. 17, indicates the start 
of grant to a third self-identify process. When node 110 (the 
root node) receives the idle, it then sends a grant to its lowest ^ 
numbered unidentified child port, the one connected to node 
114. It also sends a data_prefix to its other ports, that to node 
112. This is the same process described hereinabove with 
reference to FIG. 13, since node 114 has not yet signaled its 
self-ID completion. However, it is noted that, since node 116 10 
is identified, the data_prefix will be transmitted thereto. 

In the next step, that of completing the grant in the third 
self-identify step, illustrated in FIG. 18, after node 114 
receives the grant, it then propagates it to its lowest number 
unidentified child port (that being port #3), which is con- 
nected to node 118. Node 118 then has the opportunity to 
send self -ID information. When it is finished, it will signal 
node 114, which will label its port #3 as identified. Node 110 
will then send a grant down to its port #2 a third time, which 
will finally allow node 114 to send its self-identify 
information, since all of its child ports are now labeled as 

identified. When finished, node 114 will send the ident 

done to node 110, the root node. 

The root node 110 will be the last node to send its self -ID 
information, and when it is finished, it leaves the self-ID 
process itself and sends idle out to all its child ports. All 
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nodes exit the self-ID process with their fair bits cleared 
such that the bus will generally stay idle for the duration of 
an arbitration reset gap, unless an overeager node initiates a 
higher priority bus request. At this point, each node has a 
unique node number, and the self-ID information has been 
broadcast, the cable state illustrated in FIG. 19 for the 
self-identity phase. It is noted that the terminology "ch-i" 
indicates an identified child node. 

Referring now to FIG. 20, there is illustrated a depiction 
of the bus initialization process along a time line, llie bus 
initialization is illustrated as a bus reset point, wherein the 
system goes through a bus reset phase and then a tree-ID 
phase. The self-ID packets are then transmitted followed by 
an idle, this constituting the end of the subaction gap status. 
This is described hereinabove. 

Referring now to FIG. 21, there is illustrated a diagram- 
matic view of a self-ID packet. As noted hereinabove, the 
cable physical layer sends one to four self-ID packets at the 
base rate during the self-ID phase of arbitration. The number 
of self -ID packets sent depends on the maximum number of 
ports it has. The cable physical layer of self -ID packets have 
a format that is illustrated in FIG. 21. In FIG. 21, there is 
illustrated the configuration of the initial self-ID packet, that 
labeled "0" and the remaining self-ID packets labeled "#1," 
"#2^' and "#3.^* The field of the self-ID packets are illustrated 
in the following Table 1. 



TABLE 1 



Field 



Derived &am 



Comment 



10 

phy__id 
L 

gap_cnt 
sp 



del 



pwr 



physical_ID 

linls^active 

gap_coimt 

PHY_SFEED 



PHY_DELAY 



CONTENDER 
POWER_CLASS 



pO . . . p26 NPORT, 

child! NPORT], 
connected! NPORT] 



Self- ID packet identifier. 

Physical node identifier of the sender of this packet 

If set, this node has an active Link and Transaction Layer 

Current value for the PHY_CONFIGURATION.gap_count field 

of this node. 

Speed capabilities; 

00 98.304 Mbit/s 

01 98.304 Mbit/s and 196.608 MBit/s 

10 98.304 Mbit/s, 196.608 Mbit/s, and 393.216 Mbit/s 

11 Reserved for future definition 
Worst- case repeater data delay: 

DO ^144 ns(-14/BASE_RATE) 
01 Reserved 

10 Reserved 

11 Reserved 

If sent and the link^active flag is set, this node is a contender for 
the bus or isochronous resource manager as described in 8.4.2. 
Power consumption and source characteristics: 

000 Node does not need power and does not repeat power 

001 Node is self-powered and provides a minimnm of ISW 
to the bus 

Node is self-powered and provides a minimum of SOW 
to the bus 

Node is self-powered and provides a minumum of 45W 
to the bus 

Node may be powered from the bus and is using up to 
IW 

Node is powered from the bus and is using up to IW. 
An additional 2W is needed to enable the link and 
higher layers 

Node is powered from the bus and is using up to IW. 
An additional 5W is needed to enable the link and 
higher layers 

Node is powered from the bus and is using up to IW. 
An additional 9W is needed to enable the link and 
higher layers 
Port status: 

11 Connected to child node 
10 Connected to parent node 
01 Not connected to any other PHY 
00 Not present on this ?HY 



010 



Oil 



100 



101 



110 



111 
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TABLE 1 -continued 



Field Derived from Comment 



i 


initiated_reset 


If set, this node initiated the cuirent bus reset (i.e., it started 
sending a bus_reset signal before it received one). (Optional. If 
not implemented, this bit shall be returned as a zero.) 


m 


more_packets 


If set, another self-ID packet for this node will immediately 
follow (i.e., if this bit is set and the next self-ID packet received 
has a dififerent phy_ID, then a self-ID packet was lost). 


n 




Extended self-ID packet sequence number (0 through 2, 
corresponding to self-ID packets #1 through #3). If n has the 
value of 3 through 7, then the rsv, pa-ph, r, and m fields in 
FIG. 4—18 are reserved. 


r, isv 




Reserved for future definition, set to zeros 



Referring now to FIG. 22, there is illustrated a block 
diagram of the prior art method for handing the self-ID 
packets. In FIG. 22, the IEEE 1394 serial bus is illustrated 
as a bus 140, which is interfaced to a physical layer 142. The 
physical layer 142, as described hereinabove, is responsible 
for interfacing with the serial bus and therefore has associ- 
ated therewith a physical interface 144 for passing data from 
the bus 140 to a receiver 146 during reception of data, and 
receive data from a transmitter 148 during transmission of 
data. When transmitting data, a host interface 150 is oper- 25 
able to buffer transmit data in a transmit FIFO 152 for input 
to the transmitter 148. The receiver 146, however, is oper- 
able to receive different packets of data. These are asyn- 
chronous packets which are transmitted on a bus 154 to a 
receive FIFO 156, isochronous packets transmitted on a bus 30 
158 to the receive FIFO 156, and self -ID packets transmitted 
on a bus 160 to the HFO 156. The buses 154, 158 and 160 
are illustrated as separate buses for purposes of this example. 

The FIFO 156 can be interfaced with the host interface 
150 to a system bus 162, this, as noted hereinabove, being 35 
the 32-bit bus for this embodiment. Host interface 150 
interfaces with various general purposes registers 164 that 
are part of the host operating system and will not be 
described herein. One of the disadvantages to the above- 
noted system is that the software operates such that all of the 
self-ID packets received from the bus 140 are stored in the 
FIFO 156 for later evaluation by the host interface 150. 
When the host interface 150 evaluates the self-ID packets, it 
can determine if there is an integrity problem with the 
self-ID packets and, therefore, can initiate the bus reset to 45 
start the bus initialization, tree-ID and self- ID processes all 
over. This, therefore, requires a relatively large receive FIFO 
to store all of the self-ID packets. 

Referring now to FIG. 23, there is illustrated a block 
diagram depicting the preferred embodiment of the present 50 
invention. In this embodiment, the received asynchronous 
packets and the isochronous packets are still received on the 
busses 154 and 158, but are stored in a smaller FIFO 166. 
The FIFO 166 is smaller since it is not, in the preferred 
embodiment, going to be utilized to store the self -ID pack- 55 
ets. The self -ID packets are passed through a bus 168 to a 
hardware "self-ID snooper" 170, which is operable to pro- 
vide verification of the self-ID packets and isochronous 
resource manager information, and only transmit the veri- 
fication information to the general purpose registers 164 via 
a bus 172. The host interface 150 does not perform the 
verification. Since the verification is performed in the 
hardware, it is substantially faster. During this monitoring 
procedure, the following operations are monitored: 

1. Monitor and verify the integrity of each self-ID packet; 55 

2. Monitor and record the number of nodes in the net- 
work; 



3. Monitor and verify the Gap Count reported by each 
self -ID packet; and 

4. Monitor and record the IRM node ID. 

For comparison purposes, the prior art process will be 
described with reference to the flow chart in FIG. 24, as 
compared to the operation of the self -ID snooper in the flow 
chart of FIG. 25. With specific reference to the flow chart of 
FIG. 24, the process is initiated at a block 174, and then 
proceeds to a block 176 wherein the self-ID process begins. 
The system then flows to a block 178 to receive the self-ID 
packet, and then to a block 180 to store the self-ID packet 
to the FIFO 156. This will continue looping back through an 
"N" path to the block 178 until the self-ID period is 
complete. At this point, the program will flow along a "Y" 
path from the decision block 182 to a function block 184 
wherein the software of the host interface system 150 will 
read the self -ID packets stored in the FIFO 156 and then 
perform the following processes: 

1. Monitor and verify the integrity of each self-ID packet; 

2. Monitor and report the number of nodes in the network; 
and 

3. Monitor and record the IRM node ID. 

The program will then flow to a block 186, indicating the 
actual processing operation, which results in a large delay 
for the self-ID verification. The program then flows to a 
block 188 to end the process. 

With reference to FIG. 25, there is illustrated a flow chart 
depicting the operation of the embodiment of FIG. 23. The 
process is initiated at a block 190, and then proceeds to a 
block 192 wherein the self -ID process is initiated. The 
program then flows to block 194 to receive the self-ID 
packet from the bus, and then to a block 196. Block 196 
indicates the operation of the self-ID snooper block 170. 
This performs the above-noted operations of the block 170 
for verifying the integrity of each ID packet, reporting the 
number of nodes in the network, verifying the Gap Count 
reported in each self -ID packet, and recording the IRM node 
ID. This is aU done in hardware and, therefore, proceeds at 
a relatively higher speed than that of the process of FIG. 24 
and does not require processor time of the host interface 150. 
This is done "on the fly.^* Once this is achieved for the given 
received self -ID packet, the program will flow to the func- 
tion block 198 to determine if the self-ID period is complete. 
If not, the program wiU flow along the "N" path back to the 
block 194 to receive the next self -ID packet. Once the period 
is complete, the program will flow from decision block 198 
along a "Y" path to a function block 200 to report that the 
self-ID period is complete and that results are available in 
the various status registers 164. The program will then flow 
to a Done block 202. The implementation of the flow of 
block 196 is faciUtated with an ASIC (Application Specific 
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Integrated Circuit). As is well known in the art, this process 
flow can be implemented in the initial design of the ASIC 
which, although it does involve the generation of various 
hardware configurations, implementation of various logic 
gates, etc., block diagrams are seldom generated for the 
implementation of such a process flow illustrated in FIG. 25. 
The implementation is done with a design flow, this design 
flow attached hereto, which logic is described in Verilog 
Hardware Description Language. 

Each of the nodes contains information referred to as a 
"gap count" relating to bus idle timing information. This 
information relates to timing of transmission of data over the 
serial bus. If, for some reason, a particular node must 
transmit at a slower rate, it will have a lower gap count 
number. When each of the nodes enters into the self-ID 
phase, it will transmit as a part of the self-ID packet gap 
count information relating to that node. For example, if one 
node had a gap count of 60, another node of 70 and another 
node of 80, this would represent that they have slightly 
different timing requirements on the bus. However, it is 
important that all of the nodes operate at the same gap count. 
Therefore, if a node at 70 were to receive the self-ID packet 
from the node at 60, it would recognize the lower gap count 
and would change the gap counter internal thereto to a vahie 
of 60. However, it would stfll transmit its original gap count 
information at gap count 70 to the other nodes. The node at 
gap count 80 would receive the self-ID packets from the 
node at gap count 60 and the node at gap count 70 would 
recognize that the node at gap count 60 was lower and set its 
gap counter to that gap connt value. This information is 
stored in the general registers and, at a later time, the timing 
requirements of that particular node will be changed to the 
lower value (assuming that node did not have the lowest gap 
count). It is noted that utilizing the hardware snooper of the 
present invention, it is not necessary to evaluate each of the 
self-ID packets after receipt of afl self-ID packets but, rather, 
a hardware snooper can merely extract the gap count infor- 
mation from a self-ID packet, perform the compare opera- 
tion and then only store the lower value. This removes the 
requirement of storing the self-ID packets and all the gap 
count information for all of the received self -ID packets. 

Referring now to FIG. 26, there is illustrated a flow chart 
depicting the operation of the isochronous resource manager 
protocol processor. This is initiated at a decision block 204, 
which loops back on itself until a bus reset is generated. 
Upon detecting a bus reset, the program will flow to a 
function block 206 to a bus reset start operation and invali- 
date the self-ID/IRM data. The program will flow along a 
path 208 to a decision block 210 to determine if the 
Subaction Gap has been received. If so, the program will 
flow to a function block 212 to update the local node ID, the 
node count, the IRM node ID, the results of the self-ID 
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verify, the results of the Gap Count verify and signal bus 
reset complete and data valid operation, and then flow back 
to the block 204. However, if the Subaction Gap has not 
been received, the program will flow to a decision block 214 
to wait for the self -ID packet to be received This will 
continue to loop back to block 210 until it is received. When 
it is received, the program will flow to a function block 216 
to update the node count, and then to a function block 218 
wherein the snooper self-ID process for the candidate IRM 
is performed. The program then flows to the function block 
220 wherein verification of the self-ID packet/quadlet is 
performed, which requires the foUowing operations: 

1. Determine if the inverted quadlet is correct; 

2. Determine if the last received sclf-ID packet is con- 
nected to afl child ports; 

3. Determine if the expected local node ID is equal to the 
actual; 

4. Determine if the received node ID is incremented by 
one over the previous received node ID (assuming that 
the receiving node also receives its own self -ID packet) 
in the received node IDs. 

5. Determine if the node IDs are equal in multi-quadlet 
self-IDs. 

6. Determine if the self-ID/inverted-self-ID phase enor is 
present; 

7. Determine if there is a node ID increment; and 

8. Determine if the Gap Count is correct. 

After making the determination noted in block 220, the 
program will flow to a decision block 222 to determine if the 
self-ID passes all checks. If so, the program wiU flow along 
the "Y" path back to the input of decision block 210 to 
determine if a received Subaction Gap has been received. If 
the self-ID does not pass checks, the program will flow 
along a "N" path to a function block 224 to store the error 
code, and then to the function block 210. It is noted that the 
only information now processed by the host system is the 
error codes. 

In summary, there has been provided a serial bus system 
operating under the EEE 1394 standard for processing the 
self-ID packets received over the bus during a bus initial- 
ization process. A hardware processor is provided which 
processes each self-ID packet individually and then sends an 
error code, if necessary, to the host processor system for 
processing thereof. 

Although the preferred embodiment has been described in 
detail, it should be understood that various changes, substi- 
tutions and alterations can be made therein without depart- 
ing from the spirit and scope of the invention as defined by 
the appended claims. 



module Bus__reset ( 
_Reset. NCik. 
contndr, // mhl 

DataOut, BusReset, FaiiGap, 
IRMWrite, 
Clearbrerr, 

NodeNumber, Nrid valid, Resid, Nodecnt, //output 
Root, Brstormint, //output 
State, Vstatc, Brcricodc //output 

); 



input _Reset; 
input NClk; 
input contndr; 

input [31:0] DataOut; 
input BusReset; 
input FaiiGap; 
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input IRMWritc; 
input Clearbierr, 
input Root; 
input [0:5] NodeNumbei; 

output Nridvalid; 
output [0:5] Resid; 

output [0:5] Nodecnt; 

output Brstormint; 
// BTD 5-22-98 
/* 

output [0:1] State; 

output [0:2] Vstate; 

V 

output State; 

output Vstate; 

output [0:2] Breircode; 

wire _Rcsct; 

wire NClk; 

wire contndr; 

wire [31:0] DataOut; 

wire BusReset; 

wire FairGap; 

wire IRMWrite; 

wire Qearbrerr; 

wire [0:5] NodeNumber, 

wire Root; 

wire loncon; 

wire selfirstquad; 

wire sel234quad; 

wire selinvertquad; 

wire selfaultquad; 

reg [0:5] eresid; 

reg [0:5] eresid_n; 

reg [0:5] nodeid_n; 

reg Nridvalid; 

reg nridvalid_n; 

reg [0:5] Resid; 

reg [0:5] resid_ii; 

reg [0:5] Nodecnt; 

reg [0:5] nodecnt_a; 

reg Brstormint; 

reg brstonmnt_a; 

always @ (posedge NCIk or negedge _^eset) 

if (Ueset) 

Brstormint » I'hO; 

else 

Brstormint = brstorinint_n; 

always @(posedge NClk or negedge Reset) 

if (!_Reset) 
begin 

No decent - #1 I'hO; //init to 0, only need one #1 
Resid - 6'h3f; //init to 3ff 

trcsid - 6'h3f; 
Nridvalid = I'hO; 

end 

else if (BusReset) 
begin 

Nodecent = #1 rhO; //init to 0, only need one #1 

Resid = 6'h3f; //init to 3ff 

ereside = 6'h3f; 
Nridvalid = I'hO; 

end 
else 
begin 

Nodecnt = #1 nodecnt_n; //only need one #1 

Resid = resid n; 

eresid » eresid n; 

Nridvalid = nridvalid_n; 

end 

// parameters for state macfaine 
parameter 

idle - 1^0, 

cap - 11)1; 

// state register declarations 
reg State, state_n; 

//for self id quadlet verification puiposes . . . 

//how to decide what is a 1st, 2nd(or 3rd or 4th), or inverted 

quadlet from a packet?? 

//for this application use: 
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//SelflD Data bits 31 / 30 / 23 

// 1st quadlet 10 0 

// 2/3/4 quadlet 10 1 

// inverted quadlet 0 1 x 

// faulty quadlet 0 0 x 

// faulty quadlet 1 1 x 

assign selfirstquad - (!DataOut(23] & DataOut(31] & 

!DataOut(30]); // first quadlet of sclf-id packet 

assign sel234quad = (DataOut[23] & DataOut[31] & 

IDataOutlaO]); //234 quadlet of self-id packet 

assign selinvertquad = (!DataOut(31] & DataOut(30l); 

y/invcrt quadlet of self- id packet 

assign selfaultquad « ((!DataOut[31] & !DataOut{30]) | 

paU0ut[31] & DataOut(30])); //fault 

assign loncon - (DataOut[22] & DataOutfll]); 

//link on & contender 
//state machine init/operation 

always @(posedge NClk or negcdgc Reset) 

if (!_Rcset) State = #1 idle; 
else State = #1 state_n; 

//state machine case statement 

always @(State or BusReset or FairGap or IRMWrite or loncon or 

selfirstquad or 

NodeNumber of eresid or contndr or 
Resid or Nodecnt or Nridvalid or DataOut 
) 

case (State) // $s fiUl_case paralleLcase 

idle: begin y^-jj^* «•««•***♦*«•»••***« 

state_n = Defaults (State); //set up defaults for all 

states 

if (BusReset) begin 

nridvalid_n = I'hO; //clear ID valid 

state_ji - cap; //wait for new data 

end 

else 5tatc_n = idle; 
end //idle**"********** ******* 

cap: begin ^/cap*** 

state„n = Defaults(State); //set up defaults 

for all states 

casex 

({BusReset,FairGap,IRMWrite,selfirstquad,loncon}) //$s fulL_case 
5T>l_xx_x__x:begin //should not happen 

but . . . 

state__n «= cap; //stay here 

end 

5'bO_lx_jLJc;begin //FairGap (& no BR) 

so we are now DONE 

nodecnt_n = Nodecnt; //hold the 

node count 

external res id address 
valid 



ercsid_n = eresid; //hold the 

nridvalid__n - I'hl; //set ID 



if (contndr & (eresid == 6'h3^) resid n = 

NodeNumber, //loc con & no ext candidates 

else if (contndr & (NodeNumber > eresid)) 
resid_n = NodeNumber; //loc con & hi NodeNumber 

else if (contndr & (NodeNumber < eresid)) 
iesid__n « eresid; //loc con & not hi NodeNumber 

else if (contndr & (NodeNumber == eresid)) 
resid_n = eresid; //loc con & error 

else resid_n = eresid; 
//not loc con, set resid by eresid 
//In this last case, we do not want to be a contender 
therefore . . . 

//we set resid to the value of eresid (external resolver id) 

which may be . . . 

//3f if no self- ids came in or . . . 

//3f if no contender capable self- id's came in or . . 

//the node id of the highest node number with linkon/contender 

bits set. 

//If a Bus Reset event occurs that is not allowed to terminate 

properly with a Fair Gap then . . . 

//the resid will stay at 3hf. Also, the signal Nridvalid will 

never go to the valid state until . . . 

//a Fair Gap after a Bus Reset occurs. 

state_n - idle; 
end 

5'bO_00_x_x:begin end 



3/22/04, EAST Version: 2.0.0-29 



6,157,972 

21 22 

-continued 



5'b0_01_0_x:begin end 
5'b0_01_l_0:nodecnt__n = Nodecnt+1; 
5'b0_01_l_l:begin 

nodecnt_n = Nodecnt+l; 

cresid_n = DataOut[ 29:24]; 

end 

default: begin end 
endcase 

end //cap******************** 

endcase //end of state machine 

//hack mm add s el fid packet verification logic 

wire verinv; 

wiie verphyideq; 

reg verallchild; 

reg verallchild_ji; 

wire [0:5] curphy id; 

reg [0:5] hcldphyid; 

reg [31:0] lastsid; 

wire veiphyidincl; 

wire veiphyidincl; 

reg [0:2] Brerrcode; 

reg [0:2] brerrcode_n; 

reg [0:5] exnodeid; //expected node id 

reg [0:5] einodeid__n; 

reg incby2ok; //phy id increment by 2 is ok 

reg incby2ok_n; 

reg selejdnvquad; //expect as inverted quad 

//need to check for +1 or +2 in case this node sent a self id 
packet out 

assign verphyideq = (curphyid heldphyid); 

//current phy id equals last 
assign verphyidincl = (curphyid = (heldphyid + 6111)); 

//current phy id - last +1 
assig;n veiphyidinc2 - (curphyid — (heldphyid + 6112)); 

//current phy id = last +2 
assign curphyid » (Da taOut[ 29:24]); 

//current phy id 
assign verinv » (DataOut[31 :0] == -lastsid); 

//current packet is invert of last 
always @ [posedge NClk or negedge _Reset) 
if (!__Reset) exnodeid « #1 6'hO; //init e]q)ected node 

id 

else if (BusReset) exnodeid = #1 6'hO; //init at BusReset 

else exnodeid = #1 exnodeid_ji; //get info elsewhere 

always @ (posedge NClk or negedge _Reset) 
if (!_Reset) incby2ok = #1 I'hl; //init inc by 2 

else if (BusReset) incby2ok = #1 I'hl; //init at BusReset 

else incby2ok «> #1 incby2ok_n; //get 

info elsewhere 

// BTD S-22-98 to fix out of sync, problem which create Brerrcode 

and Brstormint interrupt 

/* 

always @ (posedge NClk or negedge _Rcsct) 

if (!_Rcset) selcxinvquad = #1 I'hl; //init to one 

since first BRF is header quad 

else if (BusReset) selexinvquad = #1 I'hl; //init at 
BusReset 

else if (IRM Write) selexinvquad = #1 ! selexinvquad; //toggle 
at each IRMWrite 

else selexinvquad » #1 selexinvquad; //get info 

elsewhere 

V 

always @ (posedge NClk or negedge _Reset) 

if (!_Reset) selexinvquad = #1 I'hO; //init to 0 

since first BRF is header quad 

else if (BusReset) selexinvquad = #1 I'hO; //init at 
BusReset 

else if (IRMWrite) selexinvquad «» #1 t selexinvquad; //toggle 
at each IRMWrite 

//look for all child indication in last selfid packet quadlets 
//if this node is root then the last self-id packet received will 
not be "all child" 

always @ (posedge NClk or negedge _Reset) 
if (l_lReset) verallchild = #1 I'hl; //default to no error 
else if (Root) verallchild » #1 I'hl; //we are root, last 
selfid will not be all child 

else verallchild - #1 verallchild_n; //get info elsewhere 

always @ (posedge NQk or negedge _Resct) 

if (I_Reset) Brerrcode = #1 3'hO; //init 



3/22/04, EAST Version: 2.0.0.29 



6,157,972 

23 24 

-continued 



else if (BusReset) Brerrcode = #1 3'hO; //hack mm 

070996 clear on Bus Reset 

else if (Clearbrerr) Brerrcode = #1 3'hO; //dear error 

code 

else Brerrcode « #1 bTerrcode_n; //else capture 

error data 

// parameters for state madiine 
parameter 

vidle = l-bO, 

vcheck - Itl; 
// state register declarations 
reg Vstate, vstate_n; 
//state machine init/operation 
always @ (posedge NClk or negedge _Reset) 
if (!_Reset) Vstate - #1 vidle; 

else Vstate - #1 vstate n; 

//state machine case statement 

always @( Vstate or Fair Gap or BusReset or IRM Write or 

verallchild or verphyidincl or verphyidinc2 or verphyideq 
or verinv oi 

selfirstquad or sel234quad or selinvertquad or selexinvquad 

or 

selfeultquad or cuiphyid of NodeNumber of cxnodeid or 
incby2ok or Brerrcode 
) 

case (Vstate) // $s full_case parallel_case 

vidle: begin //vidle"** ******* "■*****•'** 

vstate_n = Vdefaults (Vstate); //set up defaults for all 

states 

if (BusReset) vstate__n = vcheck; 
else vstate_n = vidle; 
end yyyijjg** 

vcheck: 

begin yyv^^gj^* ••******•«•« 

V5tatc_n = Vdefaults (Vstate); //set up 

defaults for all states 

//hack mm 070996 this will prevent self-id verifier from getting 
out of sync when . . . 

//BusResets are not properly terminated with a FairGap 
if (FairGap) 

begin //self id process is 

done so . . . 

vstate_n « vidle; //go to idle and . . . 

if (verallchild !« 11)1) begin //see if last 

was all child 

brstoraiint__n = I'hl; 

brerrcode n = 3 'hi; //not all child 

end 

else if ((exnodeid != 6'hO) && (exnodeid != NodeNumber)) 
begin //ERROR 

brstormint n - I'hl; 

brerrcode n - 3'h2; //expect 

phyid !- phyid 
end 
end 

else if (IRM Write & selexinvquad) //first check is for 
inverted quadlet 

begin //inverted quad of self id 

if (verinv && selinvertquad) // check inverted quadlet 

has correct format 
begin 

brstormint_n = I'hO; 
else 

begin //ERROR 
brstormint^ = I'hl; 

brerrcode__n = 3'h3; //quad not inverted 

vstate_n - vidle; //go to idle 

end 

end 

else if (IRMWrite & selfirstquad) 
begin //first quad of self 

id 

if (curphyid « 6'hO) brstorniint_n - I'hO; 
//first self id packet, no increase 

else if (verphyidincl) brstormint _n • I'hO; //if 
inc by 1, no error 

else if (vcrphyidinc2 & indiyZok) 
begin //if inc by 2 & first time . . . 
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-coQtinued 



I'hO; //disallow next 2 id icrement 

I'hO; //no error for now so . . . 

curphyid -I'hl; //save as expected Phy id 



//our node id is probably 



//ERROR 



// more than 2 inc phyid 
//go to idle 



//phyid inc by 3+ 
//go to idle 



//mhl 



//ERROR 



incby2ok_n 
brstonnint__n 
exnodeid_n 
because . . . 
end 

current phy id -1 

else if (verphyidinc2 & !incby2ok) 
begin //ERROR 
brstonnint_n «« I'hl; 
brerrcode_n -* 3'h4; 
vstate_n = vidle; 
end 
else 
begin 
brstonnint__n - I'hl; 
brerrcode_n - 3'hS; 

vstatc n " vidle; 

end 
end 

/////// else if (IRMWrite & selfirstquad) 
4-15-98. same as previous else if 

else if (IRMWrite & sel234quad) 
begin 
self id 

if (verphyideq) brstormint_ji = I'hO; 
else 

begin 
brstonnint_n = I'hl; 
brerrcode_n = 3'h6; 

packet 

vstate__n = vidle; 

end 
end 

else if (IRMWrite & selfaultquad) 
begin //crroicd quadlct ERROR 

bistormint n = I'hl; 

brerrcode__n <=» 3'h7; 

quadlet 

vstate_n 

end 

else vstatc n 

check some more 

end //vcheck**** ******* ********* 

endcase // Vstate machine 
always @ (po sedge NClk or negedge _Reset) 
if (!_Reset) 
begin 

lastsid 
heldphyid 
verallchild_n 

end 

else if (BusReset) 
begin 

lastsid 
heldphyid 
verallchild_n 

end 

else if (IRMWrite & DataOut[31:30] • 
begin 

self id pack from node 

lastsid =#1 DataOut(31:03; 
packet 

heldphyid « DataOut[29:24]; 
begin 
ensure no parents 

casex ({DataOut(7:2]}) 

6'blOxxxx:verallchild_n = I'hO; 

6'bxxlOxx:verallchild_n = I'hO; 

6'bxxxxlO:verallchild_ji - I'hO; 

default: verallchiid_n - I'hl 
no error 

endcase 
end 

end 

else if (IRMWrite & DataOut(31 :30] - 
begin 

self id pack from node 



//2,3, or 4 quad of 



> vidle; 



> vcheck; 



- #1 32'hO; 

- 6'hO; 
o I'hl; 



. #1 32'hO; 
• 6'hO; 
. I'hl; 



//phyid not equal in 
//go to idle 



//faulty 
//go to idle 
//stay and 



//in it the stored phy id 
//init to no fail 



//start over 

//init the stored phy id 
//init to no fail 

= 2'h2 & !DataOut(23]) 



//first 



//save self id 

//get the phy id 
//check this packet to 



//defbult 



2h2 & DataOut[23]) 



4th self id packet firom node 



//another 
//2,3, or 
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lastsid = #1 DataOut{31:0]; 

packet 

heldphyid » hcldphyid; 
begin 

ensure no parents 

casex ({verallchild4DataOut(17:2]}) 

17'b0 _xxxxxxxx__xxxxxxxx:verallchild_n « 

quad has a parent 

lTbl_10xxxxxx__xxxxxxxx:veraUchild_n « 

quad has a parent 

1 7'b 1 __xx 1 Oxxxx_jcxxxxxxx: veral lchild_n « 

17'bl_jcDDclOxx_joDcxixxx:veralIchild n = 

17'bl_^xxxxlO_jtxxx3txxx:verallchild_n = 
1 7'b 1 _xxxxxxxx_l Oxxxxxx: veral Ichild_n = 
17'bl_,xxxxxxxx_j£xlOxxxx:verallchild_n - 
37'bl_^xxxxxxxx_jocxxl0xx:verttllchild__n - 
17'bl_j£xxxxxxx__xxxxxxlO:vcrallchild__n ■ 
dcfeult: vcrallchild_n « I'hl; 

error 

endcase 
end 

end 

else if (IRMWrite) 
begin 

an inverted quad 

//inverted self id packet from node 

lastsid = #1 lastsid; 
packet 

heldphyid = heldphyid; 

verallchild_n = verallchild; 

child 
end 

//Default function 
function [0:1] Defaults 
input [0:1] curstatc; 
begin 

nodecnt_n = Nodecnt; 
eresid_n = eresid; 
resid_ji = Resid; 
nridvalid_n = Niidvalid; 
Defaults » curstate; 

end 

endfunction 

//second Defaxilt function 
function [0:2] Vdefaults; 
input [0:2] vcurstate; 
begin 

brstormint__n = I'hO; 
brerrcode_n = Brerrcode; 
exnodeid_n = exnodeid; 
incby2ok_n - vcurstate; 
end 

endfunction 
cndmodulc 



//save self id 



I'hO; 

I'hO; 

I'hO; 
I'hO; 
I'hO; 
I'hO; 
I'hO; 
I'hO; 
I'hO; 



//hold stored phy id 
//check this packet to 



//prior 



//cunent 



//dcfeult no 



//assume this is 



//hold self id 

//hold the phy id 

//hold the all 



What is claimed is: 2. The method of claim 1, wherein the step of processing 

1. A method for processing packetized identification occurs upon receipt of the self-ID packet. 

informatioQ over a serial bus canying data packets, which 3. The method of claim 1, wherein the step of processing 

packetized identification information is utilized by each operates without substantially buffering the self-ID packet, 

node in a network for self-identifying itself on the network, s^ch that the received self-ID packet is processed on the fly. 

and at each node, comprising of the steps of: 4 xhe method of claim 1, wherein there is bus idle timing 

monitoring the data packets received firom the serial bus 55 information contained within the self-ID packets transmitted 

during a self-ID process; ^y^j- j^jjg serial bus that indicates the bus idle timing infor- 

recognizing that the data packet received is a self-ID mation at the transmitting node, and further comprising: 

packet, which self-ID packet comprises data placed on recognizing the occurrence of self-ID packets; 

the senal bus by other nodes on the serial bus to ^ . . . -^i • ^ *• -.u 

identify those other nodes to all remaining nodes on the comparing the previous bus idle timmg mformation with 

serial bus* received bus idle timing information; and 

processing each of the recognized self-ID packets with a choosing the larger of the two compared values for the bus 

hardware processor to verify the integrity of the idle timing information and setting that value to the 

received self-ID packet in accordance with predeter- current bus idle timing information for use after the 

mined criteria; and self -ID process by the receiving node. 

generating an error signal if any of the self- ID packets 65 5. The method of claim 1, and further comprising main- 
fails to verify in accordance with the predetermined taining a count of the self-ID packets received from the 
criteria. serial bus and determining the niunber of nodes on the bus 
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from which self -ID packets were received, such that a count 
of the nodes can be maintained at each node. 

6. An apparatus for processing packetized information 
over a serial bus carrying data packets, which packetized 
identification information is utilized by each node in a 5 
network for self-identifying itself on the network, and at 
each node, comprising: 

a bus interface for interfacing to the bus; 
a receiver for receiving from said bus interface data from 

the bus, the data including self -ID packets; 
a self-ID processor for recognizing that the data packet 
received is a self-ID packet, which self-ID packet 
comprises data placed on the serial bus by other nodes 
on the serial bus to identify those other nodes to all 
remaining nodes on the serial bus; 

said self-ID processor processing each of the recognized 
self -ID packets to verify the integrity of each of the 
received self-ID packets in accordance with predeter- 
mined criteria; and 20 

said self-ID processor generating an error signal with any 
of the self-ID packets fails to verify in accordance with 
the predetermined criteria. 



30 



7. The apparatus of claim 6, wherein said self -ID proces- 
sor operates upon receipt of the self-ID packet to process the 
recognized self-ID packet. 

8. The apparatus of claim 6, wherein said self-ID proces- 
sor operates without substantially buffering said received 
self-ID packet, such that the received self -ID packet is 
processed on the fly. 

9. The apparatus of claim 6, wherein there is bus idle 
timing information contained within the self-ID packets 
transmitted over the serial bus that indicates the bus idle 
timing information at the transmitting node, and further 
comprising: 

a subprocessor for recognizing the occurrence of the bus 
idle timing information within the self-ID packets; 

a comparator for comparing previous bus idle timing 
information with the received bus idle timing informa- 
tion; and 

said comparator choosing the larger of the two compared 
values for the bus idle timing information and setting 
that value in an internal register to the current bus idle 
timing information for use after the self-ID process by 
the receiving node. 
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